Subject: APPN MIB removal candidates

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Thu, 14 Sep 95 12:36:28 EDT

Reference:  Bob Clouston's August 1 note

One of Bob's candidates for removal is:

> appnLocalTgTable
> (replace with appnLocalVRNTable, which has
>   index=appnLocalVRNName, appnLocalVRNTgNum
>   and rows appnLocalVRNPortName and appnLocalVRNOperational)

We don't quite understand what Bob is proposing here--maybe he can
clarify this before our Monday teleconference:

1.  Would the appnLocalVRNTable have *only* these four columns, or are
    these just examples?  If it's just these four, what happened to all
    of the other information for TGs to VRNs?

2.  What's special about TGs to VRNs, that made it necessary to create
    their own table for them?  Equivalently, how are TGs to *real*
    partner nodes accommodated with Bob's proposal, and why doesn't
    this work for TGs to VRNs as well?

3.  Won't a management application now have to interact with two
    different tables in order to learn about all of a node's TGs?  If so,
    we think that's a *strong* argument against removing the
    appnLocalTgTable--in other words, there would have to be a
    significant benefit to the agent to outweigh the additional burden
    being placed on the management application.

Bob

---

From: Bob Clouston <[email-masked]>
Date: Thu, 14 Sep 95 18:05:36 EDT

>     these just examples?  

My proposal was the have only those 4 columns.

>     If it's just these four, what happened to all

If the local node is an NN, this information is already in the nnTopo
table.  If the local node is an EN, this information is missing.
I won't defend removing it because I think you've hit upon a better
proposal than mine, below.

>     their own table for them?  

The port associated with the VRN is missing.  I think this is important.

>     Equivalently, how are TGs to *real*

With my proposal, all other TGs are represented in the LinkStation table.
I've already proposed a new ActivateableOnDemand column, which you can use
with the LinkState to infer the TG status.
Why can't this work for VRNs?  You're right, it can!  So we can just get
rid of the appnLocalTgTable without replacing it with my proposed
VRN table.  I think I had already proposed adding a destination node type
in the Ls table, one of its values can be virtualNode.
The Ls table already has the port name and all of the routing characteristics 
for the link/TG.  The RSN value is not important in local topology.

I do think we need 3 states for CpCp sessions now (this is independent of
the VRN issue.  It would probably be an issue whether or not we collapse
the localTG table into the Ls table):
1) configured value for the link
2) XID negotiated value
3) actual status
Its not clear which of 1 or 2 is covered by CpCpSessionSupport.
3 is covered by CpCpSessionState.

So I amend my proposal to remove the appnLocalTgTable and make allowances
in the Ls table to handle VRNs.  

>     being placed on the management application.

This no longer applies since everything is in the Ls table.

> Bob

Bob Clouston